Field
Embodiments of the present invention generally relate to software-defined networking (SDN). In particular, embodiments of the present invention relate to an SDN switch configured to provide physical data path chaining or service group chaining to, among other things, sequentially serve multiple network security devices.
Description of the Related Art
Global Internet Protocol (IP) traffic has increased fivefold in the last five years, and is expected to increase another threefold over the next five years. As the number of mobile devices and other IP devices connecting to the Internet are growing very rapidly, data traffic that needs to be monitored and inspected by network security devices is also increasing. Such increasing data traffic from different types of devices is creating new vulnerabilities that need to be monitored/inspected and controlled by the network security devices. As new types of network security issues are emerging, the network security devices need to include new policy rules to monitor and control the data traffic to/from a secured network. It is becoming difficult for hardware based switches or network security devices to provide the required scalability for rapidly increasing data traffic and increasing policy rules. To overcome the limitations of the hardware based switches or network security devices, which lack the flexibility of incorporating new and different forwarding rules, SDN devices that allow updates at regular intervals have been proposed for providing scalable and fast processing of network packets. With such features, typical SDN devices, e.g., SDN switches, are moving to replace, and are being configured to work in conjunction with traditional routers and switches in several high end applications, including the emerging cloud and datacenter environments where high volumes of traffic need to be monitored and filtered. SDN is an approach to computer networking that allows network administrators to manage network services through abstraction of lower-level functionality. This is done by decoupling the operating system that makes decisions about where the traffic is sent (the control plane) from the underlying hardware systems that forward traffic to the selected destinations (the data plane).
One aspect of SDN is the separation or abstraction of the control plane from the data plane. A typical enterprise network device may have a controlling element and a forwarding element within the same box that implements the SDN features. The forwarding elements are configured to receive packets, do conversion(s) if required, and forward the packets to their respective destinations based on instructions received from the controlling elements. In implementation, forwarding elements (also referred to as the data plane) receive forwarding commands from the control plane, based on which instructions the forwarding elements (also referred to as the controller) make/take a forwarding decision to be implemented in the data plane. The control plane is typically a collection of software running within a router or within a switch that uses rules that are set to identify the packet received from traffic, decide appropriate actions to be taken on the packet, and conveys the control decision to the data plane such that the data plane knows where to forward the packet(s).
To allow communications between different network devices or SDN devices, the OpenFlow protocols, including but not limited to Open Networking Foundation (ONF), “OpenFlow Switch Specification” Version 1.5.0 (Protocol version 0x06), Dec. 19, 2014 (hereafter, the “OpenFlow Protocol”), which is hereby incorporated by reference in its entirety for all purposes, are now being used. The OpenFlow Protocol intends to provide access to the data plane of a network device or an SDN device to other network devices and SDN devices, in addition to providing a protocol for device configuration. The OpenFlow Protocol was defined to increase flexibility and programmability of networks/network devices in order to allow network administrators to more easily tailor network configurations to their needs. The OpenFlow Protocol requires an SDN switch to contain a series of associative flow tables. Each entry in a table may contain ternary values for a desired selection of packet fields (e.g., Media Access Control (MAC) source and destination addresses, IP source and destination addresses, Transmission Control Prototype (TCP) port numbers, and the like). The OpenFlow Protocol defines a number of standardized packet header fields for matching as well as allowing users to add their own custom fields. Table entries are in prioritized order, and for each individual packet processed by the SDN switch, the table entries are searched in order for a matching entry. The table entries can have ternary values to match a broad selection of packets, wherein when the first matching table entry is found within the flow table, a set of actions associated with the matching flow table entry is executed. This may modify fields of the packet, for example, by setting the MAC destination field to a new value, the tables may direct an SDN switch to output the packet to a particular switch port in a particular queue, or send it to an SDN software controller, or to drop the packet. It is generally intended that when the existing flow tables do not contain a matching flow table entry, the packet is sent to the controller, which may respond by installing rules within the switch to properly process subsequently received similar packets. This accomplishes the goal of control plane and data plane separation by having the SDN controller software make the decisions concerning what flow tables are to be installed, whereas the SDN switch simply follows the directives of the SDN controller instead of making complex behavioral decisions on its own. In general, existing SDN switches are configured to be able to flexibly match against packets, and directed by the matches, perform a comprehensive set of actions to modify the packet and decide what to do with it.
SDNs that use the OpenFlow Protocols provide a high degree of dynamic flexibility to define new rules to be used, and actions to be taken by the network security devices. SDN architectures that use the OpenFlow Protocol therefore leads to adaptation of more flexible system hardware architecture and implementation to enable quick turnkey solution(s) for concurrent deployment of various types of network applications. Flexibility is also required in terms of traffic volume that the SDN controller and attached SDN switches can handle. As we know, dataflow in a network may be related/associated with different types of applications, and therefore data flow packets need different levels of treatment by the SDN switches and/or by network security devices. It is therefore desired that traffic received by the SDN switches be forwarded conditionally, evenly, and efficiently to one or more application devices such as network security devices.
In a typical data center deployment, a variety of security checks may need to be performed at different levels by different network security devices. Most of the traffic originating, transiting, or terminating in the data center is therefore subject to treatment by multiple security checks. Servicing of data center network traffic involves directing the traffic through a series of service functions to be performed by different security devices, which may be located at different places in the network or within a single device connected to the network or any combination thereof. Delivery of multiple service functions in a particular order within a datacenter (or among multiple data centers) creates many demands on the overall service delivery architecture. Such architectures may be referred to as service function chaining (a/k/a service group chaining) architectures while the list of service functions applied to the traffic is a Service Function Chain (SFC). A novel SDN switch architecture is needed to facilitate efficient utilization of the SDN switch, its flow processing unit(s) and/or multiple network security devices coupled to the SDN switch in the context of a service group chaining architecture.